在深入介紹 QUIC 的技術細節以及實作之前，我們會先簡單介紹一下 QUIC 協定的發展歷史，順便簡述一些 QUIC 身為新的傳輸層協定有什麼新的功能，這些功能又是為了解決什麼問題才被提出。

HTTP/3 現況

網際網路工程任務組 (Internet Engineering Task Force，IETF) 在今年六月份的時候正式推出 HTTP/3 的標準 RFC 9114。HTTP/3 是第三個主要版本的 HTTP 協定，裡面最受人注目的點在於正式棄用 TCP 協定而改用基於 UDP 的 QUIC 協定作為傳輸層的協定。可以說 QUIC 就是為了 HTTP/3 而開發，HTTP/3 則是仰賴著 QUIC 的特性才得以運行。

根據這篇報導，IETF今年6月正式發表HTTP/3後，W3Techs統計顯示全球前一千萬個網站中，已有四分之一採用這項新標準，乍看一下四分之一好像不是很多，但是跟上一版的 HTTP/2 比起來 HTTP/3 被大家認可並採用的速度上升的非常驚人，2015 年推出的 HTTP/2 標準到現在普及率還沒有超過 50%。

HTTP/2 的推出有個重要的目的是想要解決 Head-of-Line blocking(HOL blocking) 問題，解決 HOL blocking 的議題也是 HTTP/3 與 QUIC 協定的發展動機之一，HTTP/2 曾想利用 multiplexing 的技術在應用層解決 HOL blocking 帶來的效能瓶頸，不過卻被很多人說這只是臨時方案，並沒有從根本解決 HOL blocking 的問題，因為就算上層 HTTP 不會發生 HOL blocking 也有可能因為底層 TCP 封包遺失導致上層的 HTTP 發生一樣的問題，那 HTTP/3 + QUIC 是怎麼解決的呢? 這些議題也都會在後面的文章討論。

QUIC

QUIC(Quick UDP Internet Connections) 是 Google 提出的新一代傳輸層協定，標準文檔為 RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport，QUIC 唸作 "quick" 就說明了整個協定只為了一個目的，就是盡可能從多個不同層面讓 QUIC 可以更快的建立連線，更快的開始傳送資料，以應對現代許多講求低延遲的應用場景，在試圖降低延遲的時候，往往 TLS + TCP 的限制會成為效能瓶頸。

TCP 協定因為多年的發展還有歷史包袱註定了這個技術不能改頭換面，解決一些設計之初沒有考慮到的缺陷，所以 QUIC 只能另尋他路，將整個協定建構在 UDP 之上。

相信很多看過 QUIC 文章的人肯定看過類似上面的圖片，可以看到 QUIC 在基於 UDP 的前提下，一併將 TLS 也融入協定本身，除了改進 Handshake 的速度外，更進一步發展出 QUIC 協定的一大特色: 0-RTT 建立連線。當然這個 0-RTT 需要達成一定的條件才能實現，不過正因為 QUIC 整合了 TLS 並實現了大多數 TCP 的特性，才使得 0-RTT 變成可能。在後續講解 QUIC Handshake 的部份，我們也會詳細介紹 0-RTT 究竟是如何實現的，這個特性為 QUIC 帶來什麼優勢。

QUIC 為網路領域帶來革新是建立在不斷嘗試的基礎上，這個協定裡面充滿著各種精巧的設計，但讓 QUIC 擺脫 TCP 協定的歷史包袱，最重要的一點是 QUIC 選擇了基於 UDP 協定，並且將協定本身建立在 user space 的選擇，在 user space 建立的一大好處就是更具備彈性，以符合現代工程快速迭代的理念，有什麼錯誤都能快速修正，甚至讓整個協定設計本身都有一定的靈活性。

QUIC 的改進之處

QUIC 協定作為下一代的傳輸層協定，有很多新的改進，底下列舉幾個 QUIC 常被人提起的優點，每個議題都會再詳細深入討論

• 加速建立連線的 Handshake 流程: 0-RTT
  • QUIC 的一大賣點，透過整合原本 TCP + TLS 的冗長流程，讓整個 Handshake 更有效率
• 為了解決 HOL blocking 而採用 Stream Multiplexing 機制
  • 將原本 HTTP/2 在應用層的 multiplexing 移到傳輸層實作
• 加密封包
  • QUIC 加密了大部份的封包資料，除了傳送過程必要的 Header 資料以外幾乎都會被涵蓋在加密的範圍
    
• 傳輸機制以及 Loss Recovery
  • 解決了 TCP retransmission ambiguity 的問題，這部份會花一些篇幅探討
• 擁塞控制
  • 過往 TCP 的研究中，擁塞控制是一個非常重要的研究議題，QUIC 中的擁塞控制站在巨人的肩膀上，並沒有提出新的策略，通常默認使用 Cubic。
  • QUIC 帶來的是靈活性，由於是在 user space 實現的緣故，QUIC 可以根據自己的需求彈性的調整策略，比起在 Kernel space 的 tcp 來說，想要根據情況改變策略，或者開發速度都有很大的優勢。
• 新的 Flow Control 設計
• 連線遷移(Connection Migration)
  • 值得矚目的新特性之一，這個特性有些 lib 沒有支援，因為連線遷移涉及 load balance 的一些議題，有些 lib 會選擇讓有需求的用戶自行實現/擴充。

補充閱讀

Google 在 QUIC 標準還沒有推出正式的 RFC 時就有在 SIGCOMM ’17 發表了一篇 The QUIC Transport Protocol: Design and Internet-Scale Deployment 的論文，裡面講解了設計 QUIC 的一些想法，還有實際部屬的成效等等，雖然可能跟後續正式的 RFC 9000 有部份的差異，但是協定本身的設計理念不會改變，這篇論文十分推薦閱讀，看完之後會對 QUIC 協定的理解會更透徹。